[2026-06 LWG Motion 18] P2019R9 Thread attributes#9121
Conversation
| %FIXME: ordinary literal encoding? Literal encoding of T? What is "THE literal encoding"? | ||
| \exposid{name} is interpreted as a string in the literal encoding. |
There was a problem hiding this comment.
At this moment, I believe the literal encoding must be the ordinary literal encoding because T must be char. I wish we don't need a follow-up LWG issue for this.
| %FIXME: ordinary literal encoding? Literal encoding of T? What is "THE literal encoding"? | |
| \exposid{name} is interpreted as a string in the literal encoding. | |
| \exposid{name} is interpreted as a string in the ordinary literal encoding. |
There was a problem hiding this comment.
At this point it cannot be anything else, yeah. I'm wondering in which direction we want to resolve this though, and that depends on how likely support for more character types is in the future.
If we say "ordinary literal encoding" now, we will need to change that wording if more support is added.
| \item | ||
| \tcode{Args} is not an empty pack, and | ||
| \item | ||
| \tcode{remove_cvref_t<F Args...[0]>} is not the same type as \tcode{thread}. |
There was a problem hiding this comment.
| \tcode{remove_cvref_t<F Args...[0]>} is not the same type as \tcode{thread}. | |
| \tcode{remove_cvref_t<Args...[0]>} is not the same type as \tcode{thread}. |
| \constraints | ||
| \tcode{remove_cvref_t<F>} is not the same type as \tcode{jthread}. | ||
| \tcode{Args} is not an empty pack, and | ||
| \tcode{remove_cvref_t<F Args...[0]>} is not the same type as \tcode{jthread}. |
There was a problem hiding this comment.
| \tcode{remove_cvref_t<F Args...[0]>} is not the same type as \tcode{jthread}. | |
| \tcode{remove_cvref_t<Args...[0]>} is not the same type as \tcode{jthread}. |
| name_hint(name_hint&&) = delete; | ||
| name_hint(const name_hint&) = delete; | ||
| private: | ||
| basic_string_view<T> @\exposid{name}@; // \expos |
There was a problem hiding this comment.
Maybe we should rename this to name_, possibly in a follow-up commit or PR. Same for (size ->) size_.
Fixes #9105
Also fixes cplusplus/papers#817